home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5645 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: newshost.cyberramp.net!news
  2. From: sinan@cyberramp.net (John Noland)
  3. Newsgroups: comp.os.msdos.programmer,comp.lang.c
  4. Subject: Re: open vs fopen?
  5. Date: 20 Feb 1996 03:00:11 GMT
  6. Organization: Prose Software
  7. Message-ID: <4gbdfr$l2a@newshost.cyberramp.net>
  8. References: <uEYFxc9nX8WX083yn@mbnet.mb.ca> <4f8bev$6tr@hermes.louisville.edu> <2d3avbl60.alamito@marketgraph.xs4all.nl> <4ftusv$181@newshost.cyberramp.net> <danpop.824430285@rscernix> <4g39d4$ej8@newshost.cyberramp.net> <danpop.824525964@rscernix>
  9. NNTP-Posting-Host: ramp1-6.cyberramp.net
  10. X-Newsreader: WinVN 0.99.5
  11.  
  12. In article <danpop.824525964@rscernix>, danpop@mail.cern.ch says...
  13.  
  14. >In the above paragraph.  The "low-level I/O functions" means essentially
  15. >read/write.
  16.  
  17. That's right. I'm sorry. If that implies a comparison to the stdio routines,
  18. then either you're reading it wrong or I was ambiguous. I'll take the hit
  19. there. This whole thing was written as a response to someone asking a simple
  20. question. The other responses I read were unsatisfactory. "Uh, I think it
  21. has to do with UNIX compatibility", "fopen is buffered, open isn't", "fopen
  22. is ANSI, open isn't". While all of these responses have some validity, they
  23. don't give any feel for what the routines are good for.
  24. I tried to respond in a straightforward manner, aiming primarily at the newer 
  25. C programmer. My point that the low level routines offer excellent control 
  26. to the programmer is a valid one. That this control is especially useful for 
  27. binary files is also valid.
  28. If you were writing a relational database or the input system for a lexical 
  29. analyzer, which routines would you use? It's likely your answer differs from
  30. mine. IMO, the standard C buffered (stdio) routines are a poor choice for 
  31. either of these applications. If memory serves me, UNIX lex is written using 
  32. the stdio routines, and that's fine. It's just not the way I'd do it. 
  33.  
  34. >True (in Unix, probably false on other platforms) but irrelevant.  There
  35. >are no I/O needs that can be satisfied by one set of functions and not
  36. >by another, unless we start talking about Unix-specific features
  37. >(pipes, sockets, select()).
  38.  
  39. The original question was something to the effect of, "What is the difference 
  40. between fopen and open and when should I use one over the other?". Are you 
  41. saying I should have answered with, "They are functionally identical. There 
  42. is no difference between them, whatsoever. Always use fopen(), PERIOD!!!".
  43.  
  44. >The stdio buffering is a red herring, because it can be always disabled, if it 
  45. >isn't needed.
  46.  
  47. That's true. But if you're going to disable it, why not use the other routines? 
  48. They're smaller. I guess portablity would be a valid reason. The stdio routines 
  49. are ANSI and the others aren't. 
  50.  
  51. >In my <stdio.h> file, the constant BUFSIZ is 512. 
  52.  
  53. >Aha, I see where the magical value 512 came from.  The systems I'm working
  54. >on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
  55. >32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
  56. >buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
  57. >single density 8" floppy disk, which needs to read four sectors to fill
  58. >such a buffer.
  59.  
  60. This has an extemely condescending feel to it. Aha? Magical value? 
  61. Your claim that <stdio.h> sets the size of the buffer? The clouds
  62. have parted. I see clearly now. Dan has bestowed upon me the titles
  63. C NEWBIE and UNIX Illiterate. 
  64. BUFSIZ is in <stdio.h>. To say that the size of the buffer is set **IN**
  65. the stdio.h file is not wrong or misleading. Not by any stretch of the
  66. imagination. But you managed anyway. Since this thread is running in
  67. both the c.l.c and msdos.programmer groups, I used the value most DOS 
  68. compilers use. 
  69.  
  70. >Huh???  Where did I imply that setvbuf changes the _default_ buffer size.
  71. > Snip...
  72. >Care to mention a few examples?  Unix has had block devices for as long
  73. >as I can remember.
  74.  
  75. Sorry, Dan. Just teasing you a little bit. Trying to get your goat, as it 
  76. were. In retrospect, not a very constructive thing to do during a serious 
  77. debate on the merits of open() vs. fopen(). :)
  78.  
  79. Again,sorry Dan. It just seemed like you were bragging about UNIX and 
  80. putting down DOS (god forbid). I was hurt and offended (not really).
  81. DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
  82. most dominant OS in the world? 
  83.  
  84. -John
  85.  
  86.